home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7376 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.2 KB

  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
  4. Subject: Re: Hungarian notation - whoops!
  5. Date: 22 Feb 1996 14:00:18 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4gip1iINNjd@keats.ugrad.cs.ubc.ca>
  8. References: <30C40F77.53B5@swsbbs.com> <4fms62$c0p@goanna.cs.rmit.EDU.AU> <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> <4g9255$74s@goanna.cs.rmit.EDU.AU>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4g9255$74s@goanna.cs.rmit.EDU.AU>,
  12. Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
  13.  >It so happens that the C standard was carefully crafted to allow
  14.  >2s complement, 1s complement, AND sign-and-magnitude.
  15.  >
  16.  >I wrote:
  17.  >    But the fact that abs(x) may deliver a negative
  18.  >    number is something I have to live with the whole time.
  19.  
  20. It does so for the largest negative value. This is documented. Unfortunately,
  21. as you claim, you do have to check that yourself. And of course, to know what
  22. the largest negative value is, you can use the standard #defined manifest
  23. constants. It's not like abs() returns a negative value for any old random
  24. input. The fact of the matter is that the additive inverse of the largest
  25. negative value under two's complement simply can't be represented in a two's
  26. complement word of the same size, yet the return value from abs() is a signed
  27. quantity. Shrug.
  28.  
  29. I hear what you are saying though.
  30.  
  31.  >Kazimir Kyheku again completely misses the point by a country mile.
  32.  >
  33.  >>Not true. If you use the unsigned type, there is no such thing as overflow.
  34.  >>It's called residue math. No operation between two unsigned numbers yields 
  35.  >>undefined results. The "X % Y" operation between unsigned numbers gives you the
  36.  >>smallest positive residue of X with respect to Y. Nothing undefined or
  37.  >>overflown about that. 
  38.  >
  39.  >Kazimir, you will get a LOT further in life if you realise that people who
  40.  >disagree with you sometimes know what they are talking about.
  41.  >
  42.  >The abs function in C is defined by the standard to take SIGNED int as
  43.  >parameter and deliver SIGNED int as result.  I am not claiming now, did
  44.  
  45. You can cast it to an unsigned type. From K&R2 (A6.2):
  46.  
  47.     Any integer is converted to a given unsigned type by finding the 
  48.     smallest non-negative value that is congruent to that integer,
  49.     modulo one more than the largest value that can be represented
  50.     in the unsigned type. In a two's complement representation,
  51.     this is equivalent to left-truncation if the bit pattern of the
  52.     unsigned type is narrower, and to zero-filling unsigned values
  53.     and sign-extending signed values if the unsigned type is wider.
  54.  
  55. If the unsigned type you convert to is the same size as the signed return type
  56. from abs(), you will catch the the right absolute value in the conversion to
  57. unsigned without invoking undefined, or implementation-defined behavior.  If
  58. the unsigned type is wider, of course, the sign extension will mess you up!
  59. And this does not address the "-x" problem, to which there is no solution
  60. under two's complement arithmetic.
  61.  
  62.  >pointers to get unsigned.  I kid you not.)  By the way, "X % 0" is still
  63.  >undefined in unsigned arithmetic, so the claim that there is "nothing
  64.  >undefined" about it is not true.
  65.  
  66. That goes without saying.
  67.  
  68.  >Let me say it again:
  69.  >
  70.  >    C, like many programming languages, has two mathematically
  71.  >    simple functions on ***SIGNED*** integers:
  72.  >        -x
  73.  >        abs(x)
  74.  >    An implementation of C, or any other such language, using
  75.  >    ones-complement or sign-and-magnitude arithmetic, easily
  76.  >    delivers correct outputs for all legal inputs to these operations.
  77.  >    An implementation of C, or any other such language, using
  78.  >    twos-complement arithmetic, EITHER delivers incorrect outputs
  79.  >    for some legal inputs OR requires checking which is in practice
  80.  >    seldom offered.
  81.  
  82. For _one_ legal input. :)
  83.  
  84.  >Now, it so happens that a C compiler _is_ free to generate overflow checks
  85.  >for signed integer arithmetic, so a twos-complement implementation COULD
  86.  >guarantee "correct result or exception in all cases".  This is occasionally
  87.  >done for Pascal compilers.  I have access to three C compilers (lcc, gcc,
  88.  >and SPARCompiler cc) and if any of them has an option to check that signed
  89.  >arithmetic is done correctly I would be most grateful to be told what it is.
  90.  >
  91.  >The practical consequence of this is that responsibility for ensuring that
  92.  >the input to unary minus or absolute value is in range is passed onto the
  93.  >programmer.  It is that which I am complaining about.  It doesn't make my
  94.  >life as a programmer one teeny tiny bit easier.
  95.  >
  96.  >>The unsigned type is the ticket for portable integer modulo arithmetic.
  97.  >
  98.  >Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
  99.  >Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
  100.  >n, but the bounds on n are very very loose, and the price of portability
  101.  >is much programmer-inserted masking.
  102.  
  103. I didn't say that it wasn't. But the Ada compiler has to also do a little
  104. ``code explosion'' to ensure the same portability as your C with programmer
  105. inserted masking.
  106.  
  107.  >More importantly, while overflow in signed arithmetic is a run-time error,
  108.  >unsigned arithmetic is very often a design-time error.
  109.  >
  110.  >For example, suppose I want to count the number of times some event occurs.
  111.  >Unless I can *prove* at design time that the event can occur no more than
  112.  >65535 times, use of 'unsigned int' in C is a design-time error.  There is
  113.  
  114. True.
  115.  
  116.  >at least one "commodity ISA" with a 300Mhz implementation getting close.
  117.  >How long is a 32-bit unsigned counter usable with 3e8 events per second?
  118.  >
  119.  >A little over 14 seconds.
  120.  >
  121.  >Overflows aren't the problem.  Restricted machine arithmetic is the problem.
  122.  
  123. Not much you can do about the machine, as a programmer and  supporting
  124. multi-precision arithmetic in any language imposes a lot of overhead and code
  125. explosion. The C standard does give you a minimum maximum unsigned integer of
  126. 2^32-1. If you need a counter that has more precision, you can use more such
  127. numbers. That it's a pain and inconvenience, I will not deny. I also won't deny
  128. that it will give poor performance on a machine where higher precision
  129. quantities can be directly manipulated. Hence we have C progams littered with
  130. #ifdefs.
  131.  
  132. Ideally, you should be able to specify in a program the expected range for an
  133. integer, so that the compiler will either fail to translate, or generate the
  134. extra arithmetic code for maintaining the given precision. That sort of goes
  135. against the spirt of C, which is that operations are usually implemented
  136. using suitable idioms of the target architecture. It seems that this philosophy
  137. is ultimately the source of your (and other people's) understandable
  138. frustrations. 
  139.  
  140.  >>You need unaligned access if you want to have packed character arrays.
  141.  >
  142.  >Sorry, but this simply isn't true.  It may surprise you to know that Pascal
  143.  
  144. You are right. I don't know why I wrote that, when later on I clearly
  145. contradicted that by saying that such access can be emulated with inline code,
  146. so you don't need the addressability or unaligned access at the hardware level.
  147. Let the second statement be taken as official. 
  148.  
  149. BTW do you have some sort of specific gripe with two's complement
  150. representations of integer arithmetic?
  151. -- 
  152.  
  153.